Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

drivers: add mpu6050 additional functionality #298

Open
wants to merge 1 commit into
base: dev
Choose a base branch
from

Conversation

soypat
Copy link
Contributor

@soypat soypat commented Aug 30, 2021

Create a new device type: DeviceStored. It is a "better" alternative to Device for getting acceleration+gyroscope measurements together, less bus usage, faster sample rate and less chance of a failed read, which is a common problem on the MPU6050 with high sampling frequency.

Benefits

  • One read on i2c bus per gyroscope+accelerometer+temperature (and in some cases, also magnetometer) measurements. Less overhead of getting measurements.
  • Smart choice for a IMU interface since you may want to pass the IMU handle around but don't want other libraries re-reading i2c bus. MPU6050 has sampling rate issues and reads may fail at high sample rates.

Disadvantages

  • data structure consumes 14-20 more bytes
  • Must call Get or Update before calling a measurement function though this could be remedied by embedding the type within a sample rate limiter.

I'd also raise an idea I have in mind with this PR: creating an interface called ARS/AHRS or something of the sort:

// ARS Attitude reference system for complementary filter and other basic filters.
type ARS interface {
    Get() error
    Acceleration() (ax,ay,az int32) // micro gravities
    Rotation() (gx, gy, gz int32) // microradians would be ideal for these, right now it's in microdegrees
}

// AHRS Attitude-Heading reference system used by sensor fusion libraries which 
// implement filters such as Madgwick or Mahony.
type AHRS interface {
    ARS
    North() (mx, my, mz int32) // micro teslas
}

Working with the Raspberry Pi Pico for bus baud above 40kHz.

@soypat soypat marked this pull request as ready for review September 1, 2021 11:38
@aykevl
Copy link
Member

aykevl commented Sep 5, 2021

Let's first reach a conclusion in #299 before merging this.

Regarding the code: I think it would be fine to merge the two (Device and DeviceStored). That avoids duplication and I think the extra RAM consumption is not a big problem.

@VirgilioRodrigues
Copy link

Hi, sample per second?

@soypat
Copy link
Contributor Author

soypat commented Jul 2, 2022

Hi, sample per second?

Depends on your microcontroller. If using a raspberry pi pico you will be limited by the MPU6050's max sample rate, by far.

@VirgilioRodrigues
Copy link

I'm looking for solutions for acquiring vibration mechanisms, using Mpu 6050 and 9250 and 9250... I'm finding it quite difficult.... I have to isolate the MPU usage for the accelerometer function, find the connection too....

@soypat
Copy link
Contributor Author

soypat commented Jul 15, 2022

@VirgilioRodrigues What issues are you having? Is the sampling rate insufficient?

Keep in mind in nominal conditions you'll rarely be getting more than 1kHz sampling frequency. I2C baud, supplied voltage and configuration can further limit this value to well below 1kHz. for best results use high I2C baud (400kHz should be more than enough) and configure the sampling frequency to be as high as possible.

I'm not sure if current driver sets it at highest, this PR had the intention of letting users modify the sampling frequency.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants